\chapter{SmartCard}
\label{cha:SmartCard}

\section{Introduction}

The smart card is a small card that provides an integrated circuit inside. It is
also called chip card or Integrated Circuit Card (ICC). This integrated circuit
can be both a memory and a microprocessor, which stores data, processes it and
provides methods to protect it against any type of manipulation. The
typical smart card is put on plastic of classic credit card size as shows
Figure ~\ref{fig:4-smart-cards}:

\begin{figure}[htbp]
\begin{centering}
\includegraphics[width=0.5\textwidth]{4-smart-cards.png}
\caption{Example of a typical Smart Card. Figure taken from Pallisade,
Application Security Intelligence
\cite{4:smartcard}}
\label{fig:4-smart-cards}
\end{centering}
\end{figure}

According to Eurosmart \cite{4:eurosmart}, the global shipment of smart cards
have grown  a 10 per cent  in 2010 to 5455 billion cards. On the other hand, markets
that traditionally work with other technologies such as bar codes or magnetic strips,
are migrating to smart cards. But this does not stop here because they are being
integrated in the most recent and sophisticated electronic devices, like mobile
phones.
Three types of SC are currently developed for use in mobile phone. Called Secure
Element (SE) these Smart Cards are available in three forms:
\begin{itemize}
  \item Embedded.
  \item Micro SD
  \item SIM
\end{itemize}

Here we focus on the micro SD cards since they are used in this thesis. MicroSD
or TransFlash cards correspond to a format of flash memory card smaller than MiniSD,
developed by SanDisk, adopted by the SD1 Card Association under
the name ``microSD'' in July 2005. As ``SD Association
\cite{4:sd-association}'' states: It measures only 15x11x1 mm, which gives
an area of 165 mm2. As seen in Figure ~\ref{fig:4-micro-sd} ,this is three
and a half times smaller than miniSD, which was the smallest card until the
appearance of the format microSD, and is about one tenth the size of an SD card.
Its transfer rates are not high, however, companies like SanDisk have worked on it, leading to versions that support read speeds of up to 10 Mbit / s.

\begin{figure}[htbp]
\begin{centering}
\includegraphics[width=0.5\textwidth]{4-micro-sd.png}
\caption{Picture of a micro SD card.}
\label{fig:4-micro-sd}
\end{centering}
\end{figure}

\section{Types of Smart Card}
Smartcards can be divided into two different categories, depending on
functionality and price:

begin \begin{itemize}
  \item Memory Cards
\item Microprocessor cards
\end{itemize}

Furthermore, this cards can be either contact or contactless based. It is known that the contacts are the major source of error in electromechanical
systems. That is why we are starting to use contactless cards. Besides this advantage,
this card offers very attractive new applications and higher computing speeds.
Given the convenience of this type of card, its use is becoming more widespread. To smooth the transition to this type of card, a new card
type emerges, called  dual-interface or combicards. These cards have both contact and contactless
coupling elements. They are normally used  for access control and authorization.

\subsection{Memory Cards}

This type of card typically includes an Electrically Erasable Programmable
Read-Only Memory (EEPROM), where different applications can store
their information. Access control can vary from the simplest case, that is,
a read / write protection in special areas of memory, to  other more advanced
logic, which is able to perform simple encryption.

It is common to find features in this type of card, specifically optimized
for a particular application. This has an advantage and a disadvantage.
On the one hand it limits the flexibility of the card, on the other hand it
reduces the cost. A common example of these cards are  prepaid mobile phones.

\subsection{Microprocessor cards}

Although this type of card is very flexible, sometimes the same thing happens to
the card type previously seen. The card is usually determined for a given application. Often this means that only one application
can be found on the card.
But other times a SC operating system is integrated on the card, which allows
different applications to be loaded onto the card. The basic functionality of
the card is stored in the Read Only Memory (ROM) of the smart card while the
applications of the operating system, mentioned above, are stored in the EEPROM
of the card. The smart cards now allow applications to be loaded even after the smart
card itself has been customized, it also often include microprocessor chips with high processing and
large memory capacities which enable the cards to run complex cryptographic
algorithms.

\section{Elements of a smart card}

The Figure ~\ref{fig:4-architecture}  shows the architecture of a smart card. A
smart card includes the basic elements of any computer: CPU, memory and an input/output system.
It basically consists on a secure chip for calculation and storage of critical
data and keys.

\label{fig:4-architecture}
\begin{figure}[htbp]
\begin{centering}
\includegraphics[width=0.8\textwidth]{4-architecture.png}
\caption{Architecture of a Smart Card. Figure taken from
SmartCardTech \cite{4:smartcardtech}}
\end{centering}
\end{figure}
Given the simplicity of the system, it can be integrated into an ICC. At both,
the interconnections between system elements are hidden which makes it very
difficult to intercept. This will improve safety.

\subsection{Smart card file system}

As compatibility between SC was required, standards had to be defined. One the
most important standards is the ISO 7816-4 standard \cite{4:iso7814}. In
ISO 7816-4, the smart card classifies its files according to two types: DF
(Dedicated File) and EF (Elementary File). The entire structure of the system
can be viewed as a tree, as seen in Figure ~\ref{fig:4-file_structure}. The
root of this tree is a DF called Master File (MF).

\label{fig:4-file_structure}
\begin{figure}[htbp]
\begin{centering}
\includegraphics[width=0.8\textwidth]{4-file_structure.png}
\caption{Smart Card file system}
\end{centering}
\end{figure}

The DF can be viewed as a folder where several EF's or even sub-DF's are stored.
Access control can be implemented in a Dedicated File to prevent access to
applications hosted in the inside.
The Elementary Files will store the information of the applications, each EF
contains other sub-EF's. However, an EF cannot contain a DF.
Files can be addressed using the Select File command which establishes a logical
pointer to a specific file on the SC. Through the logical pointer is it possible to
manipulate (read, write, delete, etc.) the selected file.

\section{Multiapplication smart card}

As mentioned above, many smart cards are designed specifically to meet a
particular function. If any other functionality or application is needed, the manufacturer
is forced to redesign the card and produce this new type. That is why
Multiapplication smart cards are more interesting, a multi application smart
card allows to load applications onto the card even when the card is in the
hands of a external card holder.

\subsection{Application Identifier}
As different applications coexist on one card, these applications should be
distinguishable.The Application Identifier (AID) is Specified in the ISO 7816-5 standard
\cite{4:iso7816-5} and defines a universal namespace for
applications on the smartcard. An AID consists of two parts:

\begin{itemize}
  \item Registered Application Provider Identifier (RID): having
  a fixed length of 5 bytes. RIDs are allocated by a registration authority
  and include a country code, a category of application and a specific number
  of the application referred to the same provider. RDI is a unique worldwide.
  \item      Proprietary Application Identifier Extension (PIX): variable
      length field of up to 11 bytes. This part is used by application developers to
  identify specific applications. In PIX namespace is managed by the developer
  and it has to ensure that after the concatenation of RID and the PIX, the
  identifier is unique.
\end{itemize}
  
  \section{Global Platforms}
  NOT CLEAR HOW TO WRITE THIS SECTION, not sure about which picture should i
  pick
  
  This concept refers to smart card operating systems that allow external agents
  to load applications on the smart card regardless of the manufacturer. The
  ``GlobalPlatform Card Specification v2.2 \cite{4:globalplatform}'' is the
  most important specification for application management in multi application
  smart cards. The specification is independent from any smart card operating
  system, but in practice it is the standard which is used for loading and managing
  Java based applications with the JC operating system.
  There are the following operating systems for smart cards:
  
  \begin{itemize}
    \item Java Card: Explained in Section ~\ref{section_smartcard}
    \item Multos \cite{4:multos}
    \item Basic Card\cite{4:basiccard}
\end{itemize}
    
    \section{Data Transmission}
    
    The communication between the card reader (which acts as
    the master) and card (slave) is carried out according to the ISO-7816 standard.
    This communication is half-duplex, that is, takes place in both directions of
    communication, but never simultaneously. The data exchange is always initiated by
    the host (e.g. the mobile phone or card reader) and never on the card. The
    card receives an Application Protocol Data Unit (APDU) from the host,
    performs the appropriate operations, and responds to the card reader with
    another APDU.
    
    \subsection{Transmission protocols: ``T=0'' and ``T=1''}
    
    The ISO-7816 standard covers a total of 16 protocols for data transmission.
    All of these protocols start every message with the letter ``T" accompanied
    by the symbol ``="and a number between 0 and 15. Protocols ``T = 0'' and ``T = 1''
    are predominant worldwide.``T = 0'' is byte-oriented, very simple
    constructed and has memory capacity (about 300 Byte). The block-oriented T=1
    protocol works with error detection (EDC) at the end of block. The memory requirement is about 1.100 Byte. ``T = 0'' is the only
    protocol specified in the GSM standard \cite{4:gsm} so we will focus on it in the following paragraphs.
    
    This protocol was the first to be standardized internationally. Its design was carried
    out with two clear priorities: first, the memory usage should be minimal and, secondly,
    the simplicity was to be maximal. This protocol is used in the communication
    to GSM cards making it the most used worldwide.
    
    \subsection{Application protocol data unit }
    
    The standard unit of data accepted worldwide for communication between the card and the card
    reader is the Application Protocol Data Unit (APDU). To avoid being confused
    with the TPDU, it should be noted that an APDU is used in the application
    layer while a TPDU is used in the transport layer. At the
    Application layer, two data units can be distinguished : command APDU's
    (C-APDU's) from the client towards the smart card and response APDU's
    (R-APDU's), containing the response of the smart card.
    
    \subsubsection{Command APDU's}
    
    Each C-APDU has two elements, a header and a body. The header length is 4 bytes while the length
    of the body varies depending on the amount of data sent to the card. The
    different bytes that are included in a C-APDU are shown in Table ~\ref{tab:command-apu}:
    \\
    \begin{table}[h]
\centering
\begin{tabular}{|1|1|1|1|1|1|1|}
\hline
\textbf{CLA} & \textbf{INS} & \textbf{P1} & \textbf{P2} & \textbf{Lc} &
\textbf{DATA} & \textbf{Le}\\
\hline
\multicolumn{4}{|l|}{Header}&\multicolumn{3}{l|}{Body}\\
\hline
\end{tabular}
\caption{Structure of Command-APDU}
\label{tab:command-apu}
\end{table}
\\
As the meaning of each field shown in the Table ~\ref{tab:fields-command-apdu}:

\\
\begin{table}[h]
\centering
\begin{tabular}{|1|1|1|1|}
\hline
\textbf{Field} & \textbf{Length} & \textbf{Description} &
\textbf{Abbreviation}     \\ & \textbf{(bytes)} &  &\\
\hline
Class byte&1&Class of command&CLA\\
Instruction byte&1&Instruction code&INS\\
Parameter&2&Instruction parameters&P1,P2\\
Lc field&0 or 1&Length of command data&Lc\\
Command data&Lc&Command data&Data\\
Le field&0 or 1&Length of &Le\\
& & expected
response data&\\
\hline
\end{tabular}

\caption{Fields of Command-APDU}
\label{tab:fields-command-apdu}
\end{table}
\\
``Le'' and ``Lc'' are the abbreviations of ``Length expected'' and ``Length command'' respectively.
Different combinations of C-APDU's can be given depending on the data included
or if there is a ``Le'' field or not.

\subsubsection{Response APDU}

A R-APDU is composed of a body and a trailer. The body is optional and the trailer is mandatory.
There are two types of R-APDU depending on whether it consists only of a body or if instead it
consists of a body and a trailer. In the Table ~\ref{tab:response-apu}  the
elements of an R-APDU are listed.
\\
\\
\begin{table}[h]
\centering
\begin{tabular}{|1|1|}
\hline
\textbf{Data} & \textbf{SW1/SW2}\\
\hline
Body&Trailer(returncode)\\
\hline
\end{tabular}
\caption{Structure of Response-APDU}
\label{tab:response-apu}
\end{table}
\\
The length that will have the answer function is set in the field ``Le'' of the
previous C-APDU. However, this length may be zero if the smart card is forced to terminate the process either
because of an error or by receiving invalid parameters by the C-APDU. Status words SW1 and
SW2 provide the result of the execution of the C-APDU. The return codes
described in the Table ~\ref{tab:return-code}: are classified according
to the scheme used in the ISO/IEC 7816-4 standard with the following status codes:

\begin{itemize}
  \item \textbf{NP}: process completed, normal processing
  \item \textbf{EE}: process aborted, execution error
  \item \textbf{WP}: process completed, warning processing
  \item \textbf{CE}: process aborted, checking error
  \end{itemize}
  \\
  \begin{table}[h]
\centering
\begin{tabular}{|1|1|1|}
\hline
  \textbf{Returncode} & \textbf{Status} & \textbf{Meaning}\\
  \hline
  61xx&NP&'xx' bytes of data are available\\
  9Fxx&&  and can be requested using \\
  &&GET RESPONSE\\
  \hline
  62xx&WP&notifies the user of potential
  errors\\
  &&\\
  \hline
  63xx&WP&Warning; state of non-volatile \\
  &&memory
  changed.\\
  \hline
  64xx&EE&Execution error; \\
  &&state of non-volatile
  memory not changed.\\
  \hline
  65xx&EE&Execution error; \\
  &&state of non-volatile memory changed.\\
  \hline
  6700&CE&Length incorrect.\\
  &&\\
  \hline
  67xx&CE&Check errors\\
  6Fxx&&\\
  \hline
  9000&NP&Command successfully executed.  \\
  &&\\
  \hline
  
  \end{tabular}
  \caption{Table of the most important Smart Card return codes}
  \label{tab:return-code}
  \end{table}
  \\
  Even though a standard for return codes exists,
many applications define their own non-standard codes, this is also allowed by
the standard ISO 7816-4.

\subsection{Logic channels}

As noted above, in a multi-application smart card various applications can be stored.
The logical channels are the ones who make it possible to address up to four
applications at once. Although physically there is only one serial interface, at logic level it is possible to
establish up to four connections.
The class byte (CLA) of the C-APDU specifies in its two least significant bits (0 and 1) the logical channel
by which to transmit the C-APDU. External processes and the implementation of the smart card must be
synchronized and it is not allowed to interfere with a communication in progress, since the R-APDU does
not include any logical channel information. Every logical channel can be seen
as a separate smart card and a lot of memory is necessary to store all the
information and conditions.

\section{Belgium eID Card}

As mentioned in previous sections, the design of our stable mobile
anonymous petition scheme  must have a reliable means of identification for
the user, this is, secure elements. This elements will store all the secret
information necessary for the proper development of security protocols. For this thesis,
we use the Belgium e-ID card.

Due to new needs and challenges, particularly in the field of electronic
commerce and security, many countries have decided to replace their plastic identity cards
by electronic documents. In fact, Belgium is the only country that has decided to issue electronic
identity cards to all citizens older than 12.

\subsection{Card Descrption}

The original Belgian electronic identity card has the original size of a normal
smart card. Its appearance is shown in Figure ~\ref{4:belgiun-eid}:

\begin{figure}[h]
\begin{centering}
\includegraphics[width=0.9\textwidth]{4-belgian-card.png}
\caption{Belgian eID card's visual aspects. Figure taken from The Belgian Electronic Identity Card,
Danny De Cock, Christopher Wolf, and Bart Preneel \cite{4:belgian-eid}}
\label{4:belgiun-eid}
\end{centering}
\end{figure}

As you can see, the card contains the name (family name, up to two given
names, and the initial of a third name), title, nationality, place and date of birth, gender
and photograph of the holder. It also contains his written signature as well as the
civil servant that issued the card. On the card are also indicated: the expiry date
(the card is valid for 5 years), the document number and the place of delivery of
the card. All this information is also stored on the chip, called ``identity file''.
This file has a size around 200 bytes and is signed by the National Register
(RRN, \cite{4:national_register}). Besides the identity file, the Belgian
electronic identity card also has an ``address file" which occupies 150 bytes. This file will be maintained separately,
as the holder housing may vary during the period of validity of the card. The RRN
sign this file together with the identity to ensure the relationship between these two files.

On the other hand, Belgium has decided to use a photograph. This photograph is
signed through the RRN and hash file is part of the identity of the user. The chip card can perform digital
signatures as well as key generation.

In the case our thesis, obviously we will not use the original Belgian eID card,
however, we intend to have the same information in a micro SD card. Not only
that, but also seek to extend its functionality to provide cryptographic keys
and certificates used in this project.

Specifically, we use two software tools developed by COSIC research group: Quick
Key eID eID and Android Application ToolSet \cite{4:seek-for-android}. The
first allows us to create and customize an identity file, as mentioned above. The second
provides a graphical interface as described in Figure ~\ref{4:eid-android}:

\begin{figure}[h!]
\begin{centering}
\includegraphics[width=0.6\textwidth]{4-eid-android.png}
\caption{eID for Android Application screenshot. Figure taken from Seek for
Android project \cite{4:seek-for-android}}
\label{4:eid-android}
\end{centering}
\end{figure}


This application is used for viewing your data card, saving certificates or testing your PIN.

\subsection{Cryptographic Details}

The Belgian electronic identity card has three secret RSA keys of 1024 bits.
One is used to authenticate the citizen, another is used for non-repudiation
signatures and the last is used to authenticate the card to the Belgian
government. The Belgian electronic identity card is capable of performing
cryptographic signatures with any of these three keys. For authentications using
citizens and non-repudiation keys, the signature will only be done once the citizen
has entered a PIN code. This code must be selected and introduced by the citizen
through secure hardware provided for this purpose.

Each of these two keys is accompanied by a certificate that has been issued to
the citizens: the first is used within the authentication of the citizen with
SSL / TLS \cite{4:ssl} communication, this will be the protocol used in this
thesis for client/server authentication and encryption (explained in Section
REFERENCE). The second one is attached to the non-repudiation key and it is used
for electronic signatures equivalent to calligraphic signatures.

The key generation occurs during the initialization of the card. For this task,
the smart card integrates a hardware random number generator. The private key of every pair
therefore never leaves the card, which improves security. The public exponent of
RSA key pair with 1024 bits modulus has a fixed value and equal to 65537.

The card also has, in addition to the keys and certificates listed above, three specific certificates from
the government: the Belgium Root Certification Authority (CA) certificate, the Citizen CA certificate,
and the National Register (RRN) certificate.

Certification AUthorities, X.509 certificates a,d SSL/TLS protocol are seen in
Chapter REFERENCE.

\section{Java Card}
\label{section_smartcard}

Java Card is a technology that can run safely small Java applications
(Applets) on smart cards and related embedded devices. This technology is
widely used in SIM cards (used in GSM mobile phones) and electronic purse cards.

The first Java card was introduced in 1996 by several companies, like
Axalto (Schlumberger card division) and Gemplus, now fused as Gemalto. Java Card
products are based on Java Card Platform specifications
\cite{4:.jc_specification} which were developed by Sun Microsystems. The main
features of this technology are portability and security:

\begin{itemize}
  \item {\bf Portability}: Java Card aims to define a smart card
        standard that allows the same applet to run on different smart cards. Like in Java, this
  is achieved using a combination of a virtual machine (the Java Card Virtual
  Machine), and a library whose API is specified. Portability in any case, remains
  neglected in many cases for reasons of memory size, performance and execution
  time (eg for communication protocols or cryptographic algorithms).
  \item {\bf Security}: Java Card technology was originally developed for
        the purpose of securing sensitive information stored on smart cards. Safety
  is determined by various aspects of this technology:
  \begin{itemize}
    \item {\bf Data encapsulation} The data is stored in the application
          and the Java Card applications are executed in an isolated environment (the Java Card VM),
    separated from the operating system and the computer that reads the
    card.
    \item {\bf Cryptography;} On this platform are implemented the most
           commonly used cryptographic algorithms like DES, 3DES, AES, RSA (including the use of elliptic curve cryptography.)
    Other services such as electronic signature or exchange key generation are also supported.
	\end{itemize}
	\end{itemize}
  
  \subsection{Java Card JVM}
  The Java Card Virtual Machine defines a logical machine that programmers can
  easily deal with. Here are the main features of the JVM  of Java Card:
  
  \begin{itemize}
    \item Java Card's JVM is a restricted version of the Java Virtual Machine
      that supports a sub-set of Java, which can be applied to Java Card applets.
    \item To support old applications, it is provided an API dedicated to
      the development of smart card applets based on low standards ISO 7816.
    \item It has an abstract runtime environment that supports applets
      management functions, like the mechanism for selecting the applet to run.
    This environment is called JCRE (Java Card Runtime Environment).
\end{itemize}
  
  Due to technical limitations of the embedded processor on the card and some
  features such as multiprocessing, which are clearly not necessary for the cards,
  Java Card only supports a sub-set of the Java language. There are also new
  classes in the Java Card 2.0 (like javacard.framework.APDU) that are related
  to the standard ISO 7816 or cryptography.
  
  As we can see in Figure ~\ref{4:parts-jcvm} , the Java Card Virtual Machine
  is split into two parts: a converter that runs off-card and an interpreter that runs on-card.
  
  \begin{figure}[h!]
\begin{centering}
\includegraphics[width=0.9\textwidth]{4-parts-jcvm.png}
\caption{Java Card Virtual Machine architecture. Figure taken from People
UChicago, ``Java 	Cards'', \cite{4:chicago-jc}}
  \label{4:parts-jcvm}
  \end{centering}
  \end{figure}
  
  The part of the execution that occurs outside of the card involves the
  preparation of a program in a Java Card Converter, which does the work
  that is related to preparing classes, resolving references and so on. It's like
  a pre-processor.
  SHOULD I EXPLAIN CONVERTER AND INTERPRETER DEEPER??
  The second part is the execution of the bytecode (the Java assembler) on the card.
  
  The JVM is persistent, so that the status of programs and objects are preserved
  even if the card is disconnected. All related data is stored in the EEPROM
  memory. Another consequence of the JVM, is that classes are loaded and
  initialized only once and they remain active until they are deleted.
  
  \subsection{Java Card Applet}

Java Card applets should not be confused with Java applets. A Java Card applet
is a Java program that meets a set of conventions that allow them run in the
runtime environment of Java Card. A Java Card applet is not intended to run in a browser.
The reason for putting the name of applets to the Java Card applications is that applets
can be loaded into the runtime environment after the card has been manufactured.
That is, unlike many applications of embedded systems, applets do not need to be stored
in ROM during the manufacturing process.
Rather, the applets can be dynamically installed in the card at a later time to
manufacture.

Below, in Figure ~\ref{4:blog-jc}, is shown the development and deployment
processes of an applet;

\begin{figure}[h!]
\begin{centering}
\includegraphics[width=0.9\textwidth]{4-applet-development.png}
\caption{Applet development and deployment. Figure taken from Its Shakthydoss,
``Technical Blog'', \cite{4:blogjc}}
\label{4:blog-jc}
\end{centering}
\end{figure}

The main steps are:
\begin{itemize}
  \item \textbf{Design:} Specify the functionality and the interface of the
  Java Card applet.
  \item \textbf{Write code:} Implement the Java Card applet as Java source
  code
  \item \textbf{Compile:} Compile the Java Card applet using the standard Sun Java Compiler and the
  Sun Java Card Development Kit.
  \item \textbf{Convert:} Create a CAP file (=converted applet) to be loaded onto the MSC with the
  converter from the Sun Java Card Development Kit.
  \item \textbf{Test, Load and Install: } the Java Card applet on the MSC.
\end{itemize}
  
  Once the Java card applet has been created and loaded into the terminal, the
  first step is to install and register it in the Java card.
  
\begin{figure}[htbp]
\begin{centering}
\includegraphics[width=0.9\textwidth]{applet_lifecycle.png}
\caption{Lifecycle of the Applet}
\label{fig:applet_lifecycle}
\end{centering}
\end{figure}


As this method is static, the host will be responsible for creating a new
instance for the applet and register it with the JCRE, as shown in Figure ~\ref{fig:applet_lifecycle} (step 1).
Once the applet has been successfully registered, it is ready to be selected and
activated as shown in Figure ~\ref{fig:applet_lifecycle} (step 2). Only one applet can be selected and activated at a time.
If the selection of the applet is satisfactory, it is ready to process commands,
as shown in Figure ~\ref{fig:applet_lifecycle} (step 3). Any command sent to the card is embedded in an APDU
object and sent to the
processing method of the applet, while it is selected. This will continue
until the applet is deselected as shown in Figure ~\ref{fig:applet_lifecycle}
(step 4). The method to deselect the current applet must be called before a new one is selected.

\subsection{Security and visibility}

There are three main rules to control security and visibility of the applets on a Java Card:

\begin{itemize}
\item The visibility of a package is platform dependent.
\item      For a package, only public classes are visible from the
outside.
\item If an applet is able to get a reference to an object, then the applet is
authorized to use the object.
\end{itemize}

In fact, these three rules are the same as standard Java rules. In addition, most
Java card manufacturers include an additional feature of security, the firewall
between applets. This feature is global to the card, and its purpose is to
isolate each object in its own box to reduce the risk of illegal accesses.

For the development of our project, we have used the following security
packages:

\subsubsection{Package javacard.security}

The package javacard.security provides support for cryptographic functions
 supported in the Java Card platform. Its design is based on the java.security
  package.
 The package javacard.security defines a class of key called KeyBuilder (Class
 from the factory) and several interfaces that represent cryptographic keys
  used in symmetric algorithms (like DES) or asymmetric (such as DSA or RSA).
   It also supports abstract base classes like RandomData, Signature,
   MessageDigest, which are used to generate random data and compute
   verifications and signatures.

\subsubsection{Package javacardx.crypto}

Javacardx.crypto package is an extension package. It contains the
cryptographic classes and interfaces that fulfill the requirements
expressed in export regulations of the United States. The package
 javacard.crypto defines the abstract base class ``Cipher'' to support
 functions of coding and decoding.
\ \
\newline 
\newline
Javacardx.crypto and javacard.security packages define the interfaces to
applets that call for cryptographic services. However, they
provide no implementation. A JCRE provider needs to supply classes to implement
 key interfaces and extend abstract classes from
RandomData , Signature, Cipher and MessageDigest. There is usually a
co-processor in smart cards to perform cryptographic calculations.

